COMPUTER DEPLOYED METHOD OF DIRECTING NETWORK TRAFFIC, COMPUTER-READABLE MEDIA AND SYSTEM FOR NETWOR

专利摘要:
live external migration Remappable global addresses can be advertised from multiple points over the internet or other public networks. a global address can be mapped to one or more internal addresses for a provider so that when traffic is received for one network location the provider can determine whether the traffic will be processed at the current network location or at a different network location, as can be determined using a static process or a dynamic process based on any one of a number of factors. if the traffic is destined for a different network location, the traffic can be remapped and forwarded to that network location. once the traffic is at the given destination network location, the traffic can be remapped and distributed to the last destination. destination network remaps and locations can be adjusted at any time based on any of a number of factors, without significant risk of dropped traffic.
公开号:BR112013021997B1
申请号:R112013021997-1
申请日:2012-03-09
公开日:2021-09-08
发明作者:Andrew B. Dickinson；Eric Jason Brandwine
申请人:Amazon Technologies, Inc；
IPC主号:

专利说明:

BACKGROUND
[001] As an increasing number of applications and services are becoming available over networks such as the Internet, an increasing number of content, application and/or service providers are turning to technologies such as multi-user capabilities and cloud computing. These technologies allow consumers to access and/or use various types of electronic resources, physical or virtual, where the hardware and/or software used to provide these resources can be dynamically scalable to meet the needs of multiple consumers at any given time. A consumer typically leases, rents or otherwise pays for access to these features and, as such, does not need to acquire and maintain the hardware and/or software to obtain the functionality provided by these features.
[002] Using conventional approaches, a consumer can launch an instance anywhere appropriate resources are located to which there is access. If a static address is associated with this case, however, traffic destined for that static address may be interrupted in the event of a network failure or other occurrence. In some approaches, a consumer can remap an existing name (for example, a DNS name) to the public address of a new instance, but this approach may require several hours for the address to propagate across the Internet so that new instances may not receive traffic upon completion, or unavailable instances continue to receive requests. Furthermore, even when remapping addresses, the consumer can be limited to a specific region, which can be problematic in the event of a regional network outage or other type of occurrence. BRIEF DESCRIPTION OF THE DRAWINGS
[003] Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:
[004] Figure 1 illustrates an environment in which several modalities can be deployed.
[005] Figure 2 illustrates an exemplary separation of a control plane and a data plane that can be used according to various modalities.
[006] Figure 3 illustrates an example distribution of consumer network locations that can be used according to various modalities.
[007] Figure 4 illustrates an exemplary ranking list of consumer network locations that can be used according to various modalities.
[008] Figures 5(a) and 5(b) illustrate representations of mapping points in conventional approaches and according to various modalities; and
[009] Figure 6 illustrates an exemplary traffic routing process that can be used according to various modalities. DETAILED DESCRIPTION
[0010] Systems and methods in accordance with various embodiments of the present disclosure can overcome one or more of the aforementioned deficiencies and other deficiencies experienced in conventional approaches to managing traffic in an electronic environment. In particular, approaches according to various modalities offer the use of remapable addresses that are globally relocatable. These global remapping addresses allow consumers to advertise addresses from multiple points and/or network locations (eg, geographically separate regions or different network stacks operated by different providers), while allowing traffic received at those locations network is directed to the appropriate instances or other destinations at any time. Such an approach allows for dynamic traffic management without a significant risk of dropped traffic.
[0011] In at least some embodiments, a request received at a location from which a global address was advertised can be indirectly remapped and sent back to the Internet as quickly as possible, without having to use the provider's own network to drive traffic. In one example, a consumer who initiates a message in a first region that is destined for a location in a second region can have the message sent to the Internet in the first region and sent over the Internet to the second region, the components of Internet are responsible for determining how to obtain the request for the address in the second region. Such an approach prevents the provider from transferring this traffic through its own network to the second region, although in at least some modalities the provider can determine the use of a private network under certain circumstances. Such an approach allows for the migration of instances between regions for any appropriate purpose at any appropriate time. If the message is initially received in the target region, it can be directly remapped to the appropriate instance and delivered to the instance for processing.
[0012] In some of these embodiments, specific remapable global addresses can be used so that only a fraction of the address space is advertised at various points of presence (POPs) or other interface points. The fraction may be advertised on some or all POPs, and in some cases different sections of the address space may be advertised from different POP groupings. In some embodiments, the size of an address block can be selected to be large enough so that a provider can select a region from which to publish at least a portion of that space. In some embodiments, pre-allocated address blocks can be used, which can be published in some or all regions, with the understanding that a large amount of traffic may need to be transported through the provider network. A large consumer could potentially utilize a range of remapable addresses outside of the globally published block, and consider determining how to target traffic on a smaller scale. In some arrangements, addresses are advertised from more network locations than the incoming traffic can handle. In at least some modalities, certain network locations are not allowed to process certain types of traffic, such as traffic to certain consumers, etc. In some cases, a network region may advertise other specific regions to which specific types of traffic cannot be directed.
[0013] In some cases, the provider may monitor state information and automatically remap addresses as needed so that the consumer does not need to detect the drop and/or need to troubleshoot any related issues. In at least some embodiments, a consumer can specify one or more policies to specify how addresses should be remapped, and the circumstances or criteria that cause those addresses to be remapped. In some cases, a consumer can specify a policy so that certain mappings occur at regular intervals in an automated manner, which the consumer specifies in advance. In other cases, a consumer might specify that certain remapping must occur in response to the occurrence of certain types of events (for example, a region failure). Other policies may also be used, as may be established or specified by any competent authority. For example, a provider may use one or more policies to route consumer traffic, where routing is determined based at least in part on a traffic source location or address, a consumer type corresponding to the traffic, or an amount the financial contribution associated with the traffic.
[0014] In at least some modalities, a consumer may have the ability to specify and/or update static configuration information, such as adjusting the classification of target regions. For example, a consumer might want to specify that traffic be directed to a location in a region associated with Minnesota. The consumer can send an API call that specifies the updated configuration information, and this information can then be propagated as needed to update the required configuration list(s). In at least some modalities, a consumer can specify different configuration information or policies for different regions and/or at different times. In at least some modalities, it is possible to determine the state of at least one region, such as whether this location is active and available, as well as other information such as the distance to the region from the current region and the load between the current region and the possible target region.
[0015] Several policies can be deployed equally by the provider. For example, the provider might implement a policy whereby traffic is routed to different regions throughout the day. Such policies can also perform global automatic scaling, where different regions can receive, process and/or send different amounts of traffic based on time of day or other types of factors.
[0016] In one embodiment, a Domain Name System (DNS) based approach can be used, in which DNS entries for hosts have the corresponding Internet Protocol (IP) addresses changed or updated to be within the advertised range in a new region. Different IP address ranges can be advertised in different regions, and when it is desired to direct traffic to a new (or different) region, the appropriate hosts can have the DNS entries updated to include values within that new region's range. Other modalities can control data for certain protocols, such as through boundary crossing protocol (BGP) information management.
[0017] Various modalities provide a separate control environment, or control plane, which can be used to allow a user to specify and manage various aspects of a data environment, or data plane. This “self-service” functionality can be provided through a set of web services, allowing the user and control plane to act together as a virtual database administrator (DBA). A user or consumer can send a request to the control plane through one of a plurality of externally visible application programming interfaces (APIs), for example. Various APIs can be used to perform specific functions against various features in the data environment. A request received in one of the APIs can be analyzed to determine the desired action(s) to be performed on the data plane, such as actions to start a consumer instance, as well as to determine any configuration parameters to be used when starting the instance. A component such as a resource management component can determine the appropriate tasks for the action, ensure that proper startup settings are selected, and cause tasks to run in an appropriate order. At least one of these tasks is typically performed in the data environment, such as starting or tuning an aspect of a resource instance.
[0018] Several other functions and advantages will be described and suggested below, as may be established according to the various modalities.
[0019] Figure 1 illustrates an example of an environment 100 for deploying aspects according to various modalities. As will be appreciated, although a web-based environment is used for clarification purposes, different environments can be used, as appropriate, to implement various modalities. Environment 100 includes an electronic client device 102, which may include any appropriate device that operates to send and receive requests, messages or information over an appropriate network 104 and transport information back to a user of the device. Examples of such client devices include personal computers, cell phones, handheld messaging devices, laptop computers, decoders, personal data assistants, electronic book readers, and the like. The network can include any suitable network, including an intranet, the Internet, a cellular network, a local area network, or any other type of network, or a combination thereof. The components used for such a system may depend at least in part on the type of network and/or environment selected. Protocols and components for communicating over such a network are well known and will not be discussed in this document in detail. Communication over the network is allowed through wired or wireless connections, and combinations thereof. In this example, the network includes the Internet, whereas the environment includes a web server 106 to receive requests and distribute content in response to them, although for other networks an alternative device serving a similar purpose can be used, as will be evident to an element of common skill in the technique.
[0020] The illustrative environment includes at least an application server 108 and a data store 110. It should be understood that there may be multiple application servers, tiers, or other elements, processes, or components, which may be chained or linked together. otherwise configured, which can interact to perform tasks such as retrieving data from an appropriate data store. As used herein, the term "data storage" refers to any device or combination of devices capable of storing, accessing and retrieving data, which can include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed or clustered environment. The application server can include any appropriate hardware and software to integrate with the data store, as needed, to run aspects of one or more applications for the client device, handling a large part of the data access and business logic for a application. The application server provides access to control services in cooperation with data storage, and can generate content such as text, graphics, audio and/or video to be transferred to the user, which can be distributed to the user by the server. Web in the form of HTML, XML, or other appropriate structured language in this example. The handling of all requests and responses, as well as the delivery of content between the client device 102 and the application server 108, can be controlled by the web server. It should be understood that the application and web servers are not required, and are merely exemplary components, while the structured code discussed in this document can be run on any appropriate device or host machine, as discussed elsewhere in this document.
[0021] Data storage 110 may include a number of separate data tables, databases, or other data storage mechanisms and means for storing data relating to a particular aspect. For example, the data storage illustrated includes mechanisms for storing production data 112 and user information 116, which can be used to distribute content. Data storage also features a mechanism for storing log data 114, which can be used for purposes such as reporting and analysis. It should be understood that there may be many other aspects that may need to be stored in the data store, such as page image information and access rights information, which may be stored in any of the mechanisms listed above, as appropriate, or in additional mechanisms in the data store 110. The data store 110 operates, through logic associated thereto, to receive instructions from the application server 108 and obtain, update, or otherwise process the data in response thereto. In one example, a user might submit a search request for a certain type of item. In this case, the datastore can access user information to verify the user's identity, and can access detailed catalog information for information about items of that type. The information can then be returned to the user, as in a list of results on a web page that the user can view through a browser on the user's device 102. Information about a particular item of interest can be viewed in a dedicated page or browser window.
[0022] Each server will typically include an operating system that provides executable program instructions for the operation and general administration of that server, and will typically include a computer-readable medium that stores instructions that, when executed by a server processor, enable the server performs its intended functions. Suitable deployments for operating system and general server functionality are known or are commercially available, and are readily deployed by persons of ordinary skill in the art, particularly in light of the disclosure herein.
[0023] The environment in a modality is a distributed computing environment that uses several computer systems and components that are interconnected through communication links, with the use of one or more computer networks or direct connections. However, it will be appreciated by those elements of common skill in the art that such a system can operate equally well in a system that has fewer or more components than illustrated in Figure 1. Thus, the representation of system 100 in Figure 1 should be considered to be illustrative in nature and not limiting the scope of the disclosure.
[0024] An environment like the one illustrated in Figure 1 can be useful for a provider such as an electronic marketplace, in which multiple hosts can be used to perform tasks such as content distribution, user authentication, performing payment transactions, or performing any number of tasks of this nature. Some of these hosts can be configured to provide the same functionality, while other servers can be configured to perform at least some different functions. The electronic environment in such cases may include additional components and/or other arrangements, such as those illustrated in configuration 200 of Figure 2, discussed in detail below.
[0025] Approaches according to various modalities can be used with a system of a kind that can provide a relational database service ("RDS") that allows developers, consumers or other authorized users to obtain and configure relational databases and other types of data sources so that users can perform tasks such as storing, processing, and querying relational datasets in a cloud. While this example is discussed in relation to the Internet, Web services, and Internet-based technology, it should be understood that aspects of the various modalities can be used with any appropriate services available or offered over a network in an electronic environment. In addition, although the service is referred to herein as a “relational database service”, it should be understood that such service can be used with any appropriate type of data repository or data storage in an electronic environment. An RDS, in this example, includes at least one web service that allows users or consumers to easily manage relational datasets and resources without worrying about administrative complexities related to deployment, updates, patch management, backups, replay , fault tolerance, capacity management, scaling, and other types of data management aspects. Developers thus become free to develop sophisticated cloud applications without worrying about the complexities of managing the database infrastructure.
[0026] An RDS, in a modality, provides a separate “control plane” that includes components (eg, hardware and software) useful for managing aspects of data storage. In one embodiment, a set of data management application programming interfaces (APIs) or other types of interfaces is provided that allow a user or consumer to make calls to RDS to perform certain tasks relating to data storage. Dice. The user can still use the direct interfaces or APIs to communicate with the data stores, however, and can use the control plane RDS-specific APIs only when it is necessary to manage the data store or perform a similar task.
[0027] Figure 2 illustrates an example of an RDS 200 deployment that can be used according to a modality. In this example, a computing device 202 for an end user is shown with an ability to place calls across a network 206 to a control plane 208 in order to perform a task such as providing a data repository data plan 210 The user or an application 204 can access the provisioned repository directly through a data plane interface 210. Although an application and an end-user computing device are used for clarification purposes, it should be understood that any user, The appropriate application, service, device, component or resource may access the control plane and/or data plane interface(s), as appropriate, in various modalities. Furthermore, although the components are separated into data and control “planes”, it should be understood that this can refer to a real or virtual separation of at least some resources (eg hardware and/or software) used to provide its functionality.
[0028] The 208 control plane, in this example, is essentially a virtual layer of hardware and software components that handles control and management actions, such as provisioning, scaling, reproducing, etc. The control plane, in this embodiment, includes a web services layer 212, or tier, which may include at least one web server, for example, along with computer-executable software, application servers, or other types of components. The web services layer can also include a set of APIs 232 (or other types of interfaces) to receive requests or calls from web services over the network 206. Each API can be provided to receive requests so that at least one action specific to the data environment, such as provisioning, scaling, cloning, or hibernating an instance of a relational database. Upon receipt of a request for one of the APIs, the web services layer can syntactically or otherwise analyze the request to determine the steps or actions required to process or proceed with the call. For example, a web service call might be received which includes a request to create a data store. In this example, the web services tier can syntactically parse the request to determine the type of data store to be created, the requested storage volume, the requested hardware type (if any), or other types of aspects. Request information may be written to an administration data store (“Admin”) 222, or other appropriate storage location or work queue, for further processing.
[0029] A web services layer, in a modality, includes a scalable set of consumer-facing servers that can provide the various control plane APIs and return the appropriate responses based on the API specifications. The web services layer can also include at least one API services layer which, in one modality, consists of stateless replicated servers that process externally consumer-facing APIs. The web services tier can be responsible for ancillary features of web services, such as credential-based consumer authentication, consumer authorization, limiting consumer requests to API servers, validating user input, and packaging or unpacking of requests and responses. The API layer may also be responsible for reading and writing database configuration data from/to the administration data store in response to API calls. In many embodiments, the web services layer and/or API services layer will be the only externally visible component, or the only component that is visible and accessible by the control service consumers. Web services tier servers may be stateless and can scale horizontally as is known in the art. API servers, as well as persistent data storage, can be dispersed across multiple data centers in a geographic region, or close to a geographic location, for example, so that the servers are resistant to the failure of individual data centers .
[0030] The control plane, in this modality, includes what is referred to herein as a "scan" component 214. A scan component can be any suitable component that operates to sequentially query various components of the control plane or otherwise way to determine which tasks should be performed in response to an unavailable request. In this example, the web services layer can insert instructions or information about the “create database” request into administration data store 222, or a similar work queue, and the scan can periodically check the administration data store for unavailable jobs. Several other approaches can be used, as will be evident for a common skill element in the technique, such as the web services layer that sends a notification to a scan that a job exists. The scanning component can select the “create database” request, and using the information from the request can send a request, call, or other type of command to a workflow component 216 that operates to create an instance of at least one workflow for the request. The workflow, in one modality, is generated and maintained using a workflow service, as discussed elsewhere in this document. A workflow is generally a sequence of tasks that must be performed to perform a specific job. Workflow is not actual work, but an abstraction of work that controls the flow of information and the execution of work. A workflow can also be thought of as a state machine, which can manage and return the state of a process at any time during execution. A workflow component (or system of components), in one modality, operates to manage and/or perform the hosting and execution of workflows for tasks such as: creating, modifying, and deleting repositories; recovery and backup; creating, deleting, and modifying security groups; user credential management; and credential management and key rotation. Such workflows can be deployed on top of a workflow service, as discussed elsewhere in this document. The workflow component can also manage differences between workflow steps used for different database engines such as MySQL as the underlying workflow service does not necessarily change.
[0031] In this example, you can create an instance for a workflow using a workflow template to create a database and apply the information extracted from the original request. For example, if the request is for an instance of a MySQL® Relational Database Management System (RDBMS) as opposed to an Oracle® RDBMS or other instance type, a specific task will be added to the workflow, which is targeted to MySQL instances. The workflow component can also select specific tasks related to the amount of storage requested, any specific hardware requirements, or other types of tasks. These tasks can be added to the workflow in an order of execution useful for the job as a whole. While some tasks can be performed in parallel, other tasks depend on previous tasks to complete first. The workflow component or service can include this information in the workflow, and tasks can be performed and information transmitted as needed.
[0032] An example "create database" workflow for a consumer might include tasks such as ensuring that the appropriate set of startup configuration parameters are specified for the request, provisioning a datastore instance using a set of boot configuration parameters, allocate a non-instance-relative persistent storage volume, aggregate the persistent storage volume to the data store instance, and then allocate and aggregate a DNS address or other address, port, interface, or identifier that the consumer can use to access or otherwise connect to the data instance. In this example, a user is provided with the DNS address and a port address to be used to access the instance. The workflow component may manage the execution of these tasks and any other related tasks, or any other appropriate combination of such tasks, and may generate a response to the request indicating the creation of a "database" in response to the “create database” request, which actually corresponds to a data store instance in data plane 210, and provides the DNS address to be used to access the instance. A user can then access the datastore instance directly using the DNS address and port, without having to access or go through control plane 208. Several other workflow models can be used to perform similar jobs , such as deleting, creating, or modifying one or more instances of data storage, such as to increase storage. In some embodiments, workflow information is written to storage, and at least one separate execution component (not shown) pulls or otherwise accesses or receives tasks to be performed based on the workflow information. For example, there might be a dedicated provisioning component that performs job provisioning, and that component might not be called by the workflow component, but it might monitor a job queue or it might receive information for a provisioning job from either. in a number of related ways, as will be evident.
[0033] The control plane 208, in this modality, also includes at least one monitoring component 218. When a data instance is created in the data plan, the instance information can be written to a data store in the control plan , as a monitoring data store 220. It should be understood that the monitoring data store can be a separate data store, or it can be a portion of another data store, such as a distinct set of tables in a data store. administration data 222, or other appropriate repository. A monitoring component can access information in the monitoring data store to determine active instances 234 in data plane 210. As discussed elsewhere in this document, these instances can be in different regions, which can be distributed to any appropriate locations selected from around the world. A monitoring component can also perform other tasks such as collecting log and/or event information from multiple control plan and/or data plan components, such as web services layer, workflow component, component scanning, and various host managers. By using such event information, the monitoring component can expose consumer-visible events for purposes such as deploying consumer-facing APIs. A monitoring component can constantly monitor the health of all repositories and/or running instances for the control plan, detect the failure of any of those instances, and initiate the appropriate recovery process(es) .
[0034] Each instance 234 in the data plane may include at least one data store 226 and a host manager component 228 for the machine that provides access to the data store. A host manager, in one modality, is a software application or agent running on an instance and/or application server, such as a Tomcat or Java application server, programmed to manage tasks such as data storage operations and software deployment , as well as monitoring a state of the data store and/or its instance. A host manager, in one modality, detects a port that can only be accessed from internal system components, and is not available to consumers or other external entities. In some embodiments, the host manager cannot initiate any calls to the control plane layer. A host manager may be responsible for managing and/or performing tasks such as defining instances for a new repository, including defining logical volumes and file systems, installing database seeds and binaries, and starting or stopping the repository. A host manager can monitor the integrity of the data store as well as monitor the data store for error conditions such as I/O errors or data store errors, and can restart the data store if necessary. A host manager also performs and/or manages the installation of software updates and patches for the data store and/or operating system. A host manager can also collect relevant metrics, as it might refer to I/O, memory and CPU usage.
[0035] The monitoring component can periodically communicate with each host manager 228 in relation to the monitored instances 234, such as by sending a specific request or by monitoring the heartbeats of the host managers, to determine a state of each host . In one embodiment, the monitoring component includes a set of event processors (or monitoring servers) configured to issue commands to each host manager, such as getting the state of a particular host and/or instance. If a response is not received after a specified number of retries, the monitoring component can determine if there is a problem and can store the information in administration data store 222 or other type of work queue to take action for the instance , how to check for the problem and re-provision the instance if necessary. A scan can access this information and cancel a recovery workflow for the instance to attempt to automatically recover from the failure. The host manager 228 can act as a proxy (surrogate) for monitoring other control plane components, performing tasks for the instances on behalf of the control plane components. Occasionally, a problem will occur with one of the instances, such as crashing, rebooting, restarting host, corresponding instance or volume etc., which cannot be fixed automatically. In one modality, there is a logging component (not shown) that can log these and other consumer visibility events. The logging component can include an API or other type of interface so that if an instance is not available for a period of time, a consumer can make an appropriate “events” or similar API call to get the information regarding the event. In some cases, a request can be left pending if an instance fails. Since the control plan, in this modality, is separate from the data plan, the control plan never receives the data request and thus cannot queue the request for subsequent submission (although in some modalities this information can be forwarded to the control plan). Thus, the control plane, in this modality, provides the user with information regarding the failure so that the user can manipulate the request as needed.
[0036] As discussed, once an instance is provisioned and a user is provided with a DNS address or other address or location, the user can send requests "directly" to the 210 data plane over the network using a Java Database Connectivity (JDBC) or other type of client to directly interact with that instance 234. In one modality, the data plane takes the form of (or at least includes or is part of) a computing environment in cloud, or a set of web services and resources that provide data storage and access through a “cloud” or dynamic network of hardware and/or software components. A DNS address is beneficial in such a dynamic cloud environment, as availability or instance failures, for example, can be masked by programmatically remapping a DNS address to any appropriate replacement instance for a use. A request received from a user 202 or application 204, for example, can be directed to a network address translation (NAT) router 224, or other appropriate component, which can direct the request to the real instance 234 or host corresponding to the DNS of the request. As discussed, such an approach allows instances to be dynamically moved, updated, replicated, etc., without the need for the user or application to change the DNS or other address used to access the instance. As discussed, each instance 234 can include a host manager 228 and a data store 226, and can have at least one instance or backup in persistent storage 230. When using such an approach, once the instance has been configured through the plan control plane, a user, application, service, or component can interact with the instance directly through requests to the data plane, without the need to access control plane 232. For example, the user can directly issue a structured search language ( SQL) or other types of commands related to the data in the instance through the DNS address. The user would only have access to the control plane if he wanted to perform a task such as expanding the storage capacity of an instance. In at least one modality, the 208 control plan functionality may be offered as at least one service by a provider that may or may not be related to a data plan 210 provider, but may simply be a third-party service that can be used to provision and manage data instances in the data plan, and can further monitor and ensure the availability of those instances in a separate 210 data plan.
[0037] As discussed, one of the advantages of providing the functionality of a control plane as a web service or other type of service is that the control plane can function as a virtual system administrator or virtual database administrator ( DBA), for example, eliminating the need for an experienced human administrator to perform tasks such as verifying startup configurations and provisioning data. Many conventional approaches require such a human administrator to receive the necessary configuration information, determine if the configuration is valid, optimize and tune the instance, and perform other types of tasks, which require a significant amount of time and effort. Furthermore, such an approach offers many opportunities for mistakes. A user's ability to specify these parameters, however, can cause the user to launch instances or otherwise access resources in ways that are not ideal for the current system or network environment. By specifying a specific startup configuration when submitting a request for a control plan or service as described in this document, a user or consumer can achieve optimal (or at least appropriate or permitted) resource access performance. The control plan may perform the tasks necessary to create, initiate, delete, modify, expand and/or otherwise manage a resource or resource instance in response to the request. The control plane can also support several different types of resources in a consistent way, without the need for an expert on each type of resource.
[0038] In conventional modalities, a consumer can launch an instance (such as the one described in relation to Figure 2) anywhere in the world, at least where the appropriate resources are located and the consumer has access to those resources. If an address, such as a static address, is associated with a specific instance according to many conventional approaches, however, traffic directed to that static address could be lost in the event of a failure or other type of occurrence. In some approaches, an instance can be assigned two addresses at boot time: a private address and a public address that is mapped to the private address through network address translation (NAT). For IP addresses, for example, such an approach allows a consumer to remap an existing DNS name to a public IP address of a new instance using dynamic DNS. In such an approach, it can take up to 24 hours for the IP address to propagate across the Internet, however, so new instances do not receive traffic, whereas completed instances continue to receive requests.
[0039] In certain environments, a consumer may instead associate what will be termed a "remapable" address. An example of a remapable address is the “elastic IP address” offer provided by Amazon.com, Inc., of Seattle, Washington, USA. A consumer can associate a rewritable address with their account, for example, instead of associating it with a specific instance. Unlike traditional static IP addresses, however, remapable addresses allow the consumer to remap the publicly exposed IP address to any instance in their account.
[0040] Even when using remapable addresses, however, a consumer is typically limited to a single region. For example, a consumer who has a machine failure in Virginia can start a new instance in Virginia, or nearby, and remap the remapable address to that new instance. Traffic coming from a network (eg the Internet) destined for that remapable address will be routed to that instance. A customer can use multiple locations within that region, such as a series of different data centers in Virginia, so that if one data center experiences a power outage, for example, traffic can be rerouted to the other(s) data center(s) in that region.
[0041] When using conventional approaches, however, a consumer cannot remap those remapable addresses across multiple regions or to different regions. For example, a consumer cannot remap to a data center outside the United States in the event of a catastrophe or other occurrence that causes the network to go down in the United States. In addition, a consumer for whom traffic comes from essentially different regions of the world at different times cannot remap addresses to reduce the amount of network traffic at any given time by mapping to a data center closer to the most recent traffic source point. A consumer would have to allocate new remapable addresses and use a DNS or other similar mechanism to inform consumers of the new endpoint(s), which could be inconvenient in many different situations.
[0042] One option that is available to a consumer using conventional approaches is to “advertise” all public addresses in each of the desired regions. In example 300 illustrated in Figure 3, a provider can utilize resources in at least four different areas, each of which corresponds to an associated region, here the west coast of the United States (region A), the east coast of the United States ( region B), Ireland (region C) and Asia (region D). In this example, a public address space in Virginia can be advertised in Virginia, and a public address space in Ireland can be advertised in Ireland. Here, “announce” generally means that a notification is provided whereby nodes on a network, such as the Internet, are informed of the location of certain addresses (eg IP addresses) so that the destined traffic those addresses can be properly routed to that location. Since consumers typically prefer traffic to use the shortest possible path, and since these consumers also prefer to use other people's networks (eg, up at level 3 with other providers, etc.), such an approach allows traffic starting in a particular region (eg Europe) is routed through a non-consumer network (eg the Internet) to the advertised location in Europe (eg Ireland in this example). Similarly, traffic sent from within the United States may be directed over the Internet to the advertised location in Virginia, and may be received first on the consumer's network at that location. A possible downside to this approach, however, is that if Ireland's address space becomes unavailable, traffic originating in Europe may be dropped as the region is unaware of the address space in other regions.
[0043] In some cases, addresses can be generically remapped using conventional approaches. In such cases, the public address space can be advertised at all locations so that traffic can be received at any one of those locations and then routed accordingly. Such an approach can be inconvenient for many reasons, such as the fact that the entity advertising that address space would typically have to carry back huge amounts of traffic between regions, so traffic received in Ireland, which may have been received from most favorable way in Asia, could be shipped to Asia, etc. For example, a company that operates a website on the west coast may have many customers on the east coast from where traffic can be received at a data center in Virginia, which would then need to be transported through the company's network to the servers. from the west coast, meaning that the data center host or provider would need to transport the data over its own network at its own expense. Such an approach can also pose scaling problems, as the address space would need to scale globally to accommodate traffic at any location, although regions can be quite different sizes. Other types of problems can also result from such an approach.
[0044] Systems and methods according to various modalities may allow consumers to use remapable addresses that are globally relocatable and/or indirectly remapable. In at least some embodiments, a consumer using a web service through one or more application programming interfaces (APIs) can utilize and manage remapable and globally relocatable IP addresses. Such an approach allows the network to benefit from a "hot potato" approach to routing traffic, whereby a request received at one of the advertised locations can be indirectly remapped and sent back to the Internet as quickly as possible, without having to use the provider's own network to direct traffic. In one example, a consumer who initiates a message in Virginia that is destined for a location in Ireland can have the message sent to the Internet in Virginia and sent over the Internet to Ireland, with the Internet components responsible for determining the how to get the request for the address in Ireland. Such an approach prevents the data center provider from transporting this traffic over its own network to Ireland, and then from being received on the Internet only in Ireland. Since the provider typically pays for Internet bandwidth anyway, it may be preferable to use that bandwidth instead of transporting the data across the Atlantic Ocean over a dedicated fiber or other type of private connection.
[0045] Such an approach allows the migration of instances between regions for any appropriate purpose, such as locating instances closer to a large portion of users at any specific time (for example, according to a “follow the sun” around the world policy ). When using conventional Internet-based approaches, such migration can become difficult or even impossible to accomplish when instances communicate with Internet hosts. Consumers will generally want such a migration to be carried out relatively seamlessly, but this poses problems with the proper routing of traffic across the Internet. In one embodiment, a Domain Name System (DNS) based approach can be used, where DNS entries of hosts can have the corresponding IP addresses changed or updated to be in the advertised range in a new region. In such an approach, different IP address ranges can be advertised in different regions, and when it is desired to direct traffic to a new (or different) region, the appropriate hosts can have the DNS entries updated to include values in the range of that new region .
[0046] Another approach is based on data control for certain protocols, such as boundary crossing protocol information (BGP). BGP typically maintains a table of IP prefixes that are used with Internet routing decisions. In certain modalities, BGP advertisements can be altered to start publishing a specific address space in the new region and stop publishing that space in the previous region. By using such an approach, traffic can be directed directly to the new region, and the consumer keeps the same IP address. In some embodiments, a mechanism can be provided to forward and/or encapsulate traffic between regions for a period during which information from a DNS or BGP based approach is changed.
[0047] In some embodiments, specific remapable global addresses can be used so that only a fraction of the address space is advertised across multiple POPs or other interface points. Fraction may be advertised on some or all POPs, and in some cases, different sections of address space may be advertised from different POP groupings. Using conventional Internet approaches, a single IP address simply cannot be advertised globally. An entity may, however, request a block of remapable addresses and want those addresses to be accessible in more than one region, such as the eastern US region and the western US region. In such an instance, all (or a large portion) of consumers may be in the United States, but the company may want a fault tolerance capability and move traffic to the other location in the event of a problem. In some cases, a business may simply want to drive traffic based on the location of most consumers at any given time. For example, if a company has consumers around the world and these consumers tend to access the network during business hours in the part of the world they are located in, the company may want to adjust their addresses to different regions throughout the day in order to try to minimize most of the data paths needed at any one time. In one example, the consumer may receive a “/24” that can be advertised in global BGP. A “/24” generally refers to a block of Internet addresses summarized in a routing table as an address in dotted decimal notation followed by a backslash (“/”) and a two-digit decimal number it provides the number of leading bits in the subnet mask. The “/24” can then be announced from the desired region at any time. Optimal request routing can then be performed for that subset of traffic, and an appropriate amount can be charged to the consumer.
[0048] In one embodiment, the size of an address block can be selected to be large enough for a consumer so that a provider can select a region from which to publish at least a portion of that space. In another modality, pre-allocated address blocks can be used, which can be published in some or all regions, with the understanding that a large amount of traffic will need to be transported through the provider network. A large consumer could potentially utilize a range of remapable addresses outside of the globally published block, and the provider may consider determining how to route traffic on a smaller scale.
[0049] In at least some of these modalities, the consumer can still receive many characteristics related to desirable failures. When using remapable addresses in a conventional system, a consumer who has a number of remapable addresses in Virginia will have problems if there is a transit interruption in Virginia, as these addresses will be at least temporarily unavailable and requests will be discarded as soon as they are received. in the network structure. If the consumer has leased a group of remapable global addresses, however, those addresses may be mapped to Virginia, but they may be advertised in many places around the world, so when the Internet goes down in Virginia these addresses will still be advertised in all other points of presence (POPs) on the Internet. The consumer, therefore, can have an instance started in another region, and one or more of the remapable global addresses can be mapped to that instance so that the service is again quickly available. An advantage of this process is that the entire operation can be completely contained in the provider's network, so there is no lag time or delay waiting for the Internet's BGP or DNS to propagate. The consumer does not need to interact with their Internet service provider, but can instead make one or two API calls to the provider, for example, so that DNS names and IP addresses can again be readily available.
[0050] In some cases, the provider may monitor the state and may automatically remap addresses as needed so that the consumer does not need to detect the outage and/or resolve any related issues. In at least some embodiments, a consumer can specify one or more policies to specify how addresses are to be remapped, and the circumstances or criteria that cause those addresses to be remapped. In some cases, a consumer can specify a policy so that certain mappings occur at regular intervals in an automated manner, which the consumer specifies in advance. In other cases, a consumer might specify that certain remapping must occur in response to the occurrence of certain types of events (for example, a region failure).
[0051] In at least some embodiments, each region knows another region in which a consumer has an address space with a provider. There may be communications established between these regions, such as through one or more tunnels. A list of mappings can be maintained which indicates which addresses, or which address space section, is/are currently outside the region. Thus, when traffic is received in a first region for a remapable global address that is currently mapped to a second region, the provider can perform address translation and destination lookup on the received traffic to determine the destination region. The first region can determine any information other than the identity of the second region, but can direct traffic along the tunnel to the second region. Once in the second region, an appropriate routing protocol lookup can be performed as the traffic is located at that point.
[0052] In this example, regions such as Los Angeles and Virginia can always publish a certain IP address on the Internet. If a user is sitting in a store in Virginia, the local ISP will generally prefer to drop that traffic quickly using a “hot potato” routing approach. Thus, the ISP will generally direct traffic to the Virginia region. If there were an occurrence such as a Virginia traffic disruption, however, the ISP structure would still receive the Los Angeles announcement, so the structure has the capacity to transport the information to the Los Angeles area.
[0053] In some arrangements, addresses may be advertised from more regions than will actually be used to process requests. For example, a remapable global address can be advertised from each of five different regions around the world. The address itself can be mapped to two of these regions, such as instances in Virginia and Ireland. The mappings can be configured so that traffic received in Virginia is serviced in Virginia and traffic received in Ireland is serviced in Ireland. The mappings can also be configured so that incoming traffic in the West Coast region of the United States is directed to Virginia, and incoming traffic in Asia is directed to Ireland, etc. Addresses are therefore advertised in five different places, but are directed and serviced only to/by two of these locations. In at least some modalities there is no intelligence, as routing is determined by configuration. In at least some modalities, there may be built-in intelligence or policies that dictate that traffic be routed to different locations based on various factors such as current load, time of day, etc.
[0054] In some embodiments, an anycasting approach can be used, in which there is no state detection or flow checking, but traffic is directed to a specific region based on factors such as the current time zone. As used in this document, anycasting generally refers to an approach known in the art for routing traffic to a member of a group of possible recipients that are associated with the same destination address. In at least some arrangements, it can be established that static configuration information can include specific regions to which traffic will be directed at some or all times, depending on where the traffic will be received. In other embodiments, static configuration information can include an ordering or ranking of various regions to which traffic can be directed. For example, other regions can be classified based on network proximity. Thus, when traffic is expected for a particular address, a determination can be made as to where the remapable global address is active and the list can be consulted to determine the ordering of various regions. In at least one modality, traffic is directed to the region where the address is active that is in the highest position in the ranking list. In one example, a 400 ranked list like the one illustrated in Figure 4 might list (in descending order) Los Angeles, Virginia, and Ireland, and the global address for traffic might be active in Ireland and Virginia. In that case, traffic would be directed to Virginia as this is the highest ranked region where the address is active.
[0055] In at least some modalities, a consumer can specify and/or update static configuration information, such as adjusting classification at various times or at specific times. For example, a consumer might want to specify that traffic be directed to a location in a region associated with Minnesota. When using a system like the one described in relation to Figure 2, the consumer can send an API call that specifies the updated configuration information, and this information can then be propagated, as needed, to update the list(s) required configuration(s). In at least some modalities, a consumer can specify different configuration information or policies for different regions and/or at different times. Various other types of information may be included or used, as will be apparent in light of the present disclosure.
[0056] In at least some embodiments, determining the appropriate region can be more dynamic. For example, a determination can be made as to the state of at least one region, such as whether that location is active and available, as well as other information such as the distance to the region from the current region and the load between the current region and the possible target region. In one example, traffic might be received in Los Angeles and, under normal conditions, might be directed to Virginia. If there is a major networking event on the East Coast that makes Virginia currently unavailable, traffic can instead be routed to the nearest other available region, which in this case could be located in Asia. Once back online, possibly Virginia will once again be the best choice where subsequent traffic can be routed. Several other factors can also be included in the dynamic decision. For example, most of a consumer group may be on the west coast, with a relatively small presence in other locations. Consequently, the consumer may wish to request a weighted traffic balancing in which the volume of consumer traffic is directed to a specified region and a smaller amount is directed to the other regions. Any one of a number of other types of policies can equally be implemented within the scope of the various modalities.
[0057] Several policies can be equally deployed by the provider. For example, the provider can implement a “follow the sun” policy, where traffic is routed to different regions throughout the day, as discussed above, so that the average path length is reduced through the routing of the traffic based on the location of the highest load around the world as a function of the time of day, where that load moves around the world based on the relative differences between daytime and nighttime, etc. Such policies can also perform global automatic scaling, where different regions can receive, process and/or send different amounts of traffic based on time of day or other types of factors. In some arrangements, a consumer can move a website or app “around the world” every 24 hours in order to adapt to the location where a large portion of the traffic will belong relative to the current region.
[0058] It should be understood that several conventional approaches offer a certain level of global request routing solutions. For example, Akamai Technologies of Cambridge, Massachusetts, USA, offers leading-edge solutions that allow applications to run at the edge of a network, where global DNS directors can dynamically direct load based on capacity. A global DNS director can act as a load balancer that does not operate at the data plane but only conducts balancing at the DNS level. If there are two data centers in different time zones, the DNS director can obtain information from load balancers (or other components) in each time zone that indicate a volume of current capacity, and the director can weight DNS responses based on at least in part in that capacity. If there is a change in load or group membership (that is, several additional servers come online), for example, the DNS director can make decisions accordingly. Such an approach is relatively limited in terms of capacity and is not highly consistent. In addition, there will be a lag in relation to the approaches discussed in this document. Conventional approaches do not utilize remapable global IP addresses, particularly at the service provider level, and thus fail to offer several advantages or implementations in the present disclosure.
[0059] An approach that can be used to explain at least some of the differences between various modalities with respect to certain conventional systems can be described in relation to Figures 5(a) and 5(b). In Figure 5(a), a three-level representation 500 is illustrated, which includes the Internet 502 as the top layer, a service provider 504 as an intermediate layer, and an underlying protocol layer 506 (eg, a routing protocol substrate). The protocol layer is properly connected and fully mapped, and everyone participates in the same area of the protocol layer. In the conventional approach of Figure 5(a), there are many different 508 points at which the Internet “contacts” the service provider. Exactly one of these points can advertise a specific IP address for traffic routing purposes. In the approach of Figure 5(b), however, more than one of these points at which the service provider 514 contacts the Internet 512 can advertise the same remapable global IP address. Then locally, at the site where the IP address is advertised, the expected traffic for that IP can be encapsulated with protocol-specific information so that the 516 protocol layer can interconnect the various 518 sites.
[0060] In various embodiments, interconnection can be provided using other approaches where the routing protocol substrate does not exist, such as with a regular IP for NAT translation, etc. For example, traffic can be received from the Internet to a specific global IP address, which can be translated into a relatively slow mobile address that is specific to a region. Traffic can then be directed to that region, and when it arrives in the region it translates the address into the address of a real host to receive the traffic, which can involve much faster mobile mapping. In one example, two NAT translation devices can be used, where the source region is encoded in the destination IP address, where there are two or more IP addresses, and at least one of those addresses is a remapable global IP address. Traffic can be received, which is destined for a global IP address, which can be effectively remapped to a region-specific remapable IP address. Reply traffic can be remapped in a similar way.
[0061] Such an approach effectively uses unidirectional mappings instead of (or in addition to) conventional bidirectional mappings. Consider a situation with the following IP addresses:
[0062] A = remapable global IP address
[0063] B = Los Angeles specific IP address
[0064] C = internal provider IP address (eg instance/host address)
[0065] D = specific IP address for Los Angeles.
[0066] In an example where traffic is received in LosAngeles and has a destination corresponding to the global address A, this traffic can be directly mapped to the internal address C to be delivered to the appropriate instance, etc. This is similar to how routing works using conventional approaches. If traffic is instead received in another region like Virginia that is destined for global address A, Virginia can have a unidirectional mapping of A^B so that Internet traffic can be mapped to address B in Los Angeles . Since the provider can be informed that the entire address block of which B is a member is in Los Angeles, it can send traffic through the provider structure across the Internet to Los Angeles, which has a unidirectional mapping of B ^C so that traffic can be received in the intended instance. Any return traffic can then advance from C^A according to a direct remapping so that the traffic can be sent directly to the Internet without having to be transported back to Virginia.
[0067] In at least some embodiments, the region of origin can also be encoded in such an approach. For example, Ireland may have a mapping of A^D but not A^B, although both B and D are located in Los Angeles. Expected traffic for A that is received in Ireland can undergo a NAT process to change the destination address to D, whereby traffic can be sent over the fabric or WAN to Los Angeles, where a similar mapping of D^C can be performed as in the previous example. In that case, however, the system can distinguish between traffic that has entered Virginia and traffic that has entered Ireland. Such an approach allows for a determination in Los Angeles of the region (but not necessarily the instance) in which the traffic has entered. Such an approach can allow traffic between regions to be pushed back to the Internet instead of being transported back through a provider network if the intermediate IP is publicly routable. In at least some arrangements, the decision to transport back or push to the Internet can be made based on a number of factors, such as current load and transit prices.
[0068] Figure 6 illustrates an example process 600 for routing traffic with the use of global addresses that can be used according to various modalities. In this example, a remapable global address is selected for at least one instance of consumer 602. As discussed, the address can also refer to several other types of destinations. The global address can also be mapped to any appropriate internal or intermediate address 604, such as intermediate regional addresses or individual instance addresses. The global address may then be advertised from one or more regions 606, which may be in any appropriate location as discussed herein. Also, as discussed, the regions from which the global address is advertised can change at different times. When traffic is subsequently received in one of the regions that is destined for the remapable global address 608, the destination region may be determined 610. As discussed, this may be a static determination based at least in part on the configuration information, or it may be a dynamic decision based on factors such as current load, current availability, distance to a region, classification information, etc.
[0069] If the determined destination region is determined to be the same region in which the traffic was received 612, the traffic can be remapped to the internal address of the appropriate instance 614, and can be delivered to instance 616. If the region in If the traffic was received outside the destination region, as determined, the traffic may be remapped to destination region 618 and forwarded to destination region 620. As discussed, this forwarding can take place through a private provider network or a public network, depending on the various factors discussed in this document. When traffic arrives at the destination, it can be remapped and delivered to the instance accordingly.
[0070] In several modalities, similar mappings and translations can also be performed at the DNS level. For example, if a provider controls DNS for a particular host, the DNS response can be modified so that the translation is between the DNS name and the IP address, rather than between IP addresses. Such an approach can be used in place of NAT translation or other protocol-specific encapsulation, for example.
[0071] In addition, certain modalities can handle received traffic near the time of a change by different means. For example, a host with a global IP and a DNS name can have that DNS name routed to a new realm. In some modalities, all traffic received in the old region can be dropped. In at least some modalities, however, the system can direct traffic to the new region, although the last destination may not yet be known or not yet available. In still other modalities where state information is being maintained, transactions may still exist as services that were active in the previous region. Existing transactions can be processed in the old region, with new traffic being sent to the new region to prevent traffic from dropping during the transition period.
[0072] Several other approaches can equally use at least some of the features described above. For example, systems using Internet Protocol Version 6 (IPv6) can use such approaches, although IPv6 is not used with NAT, according to conventional approaches. The intermediate IP address can also be used, however, so that various address translation approaches discussed in this document can be used. In other approaches, traffic received into a region that had the first translation from the global IP to the specific IP for a region can be translated back to the globally specific IP address and delivered normally. In at least some modalities, address advertisements can be extended to cloud front-type points of presence (POPs). By using such an approach, traffic can be quickly moved to the provider network so that any desired adjustments can be made more quickly.
[0073] Several modalities can be described in view of the following clauses:
[0074] Clause 1. Computer-implemented method of directing network traffic, which comprises:
[0075] under the control of one or more computer systems configured with executable instructions,
[0076] mapping a remapable global Internet Protocol (IP) address to at least one virtual instance located in at least one network location among a plurality of network locations;
[0077] advertise the remapable global IP address from at least two such network locations;
[0078] receiving network traffic for a receiving network location from the at least two network locations from which the global remapable IP address is advertised;
[0079] determining a destination network location for network traffic;
[0080] remapping network traffic and distributing network traffic to a target instance of the at least one virtual instance when the target network location is the receiving network location; and
[0081] when the destination network location is different from the receiving network location:
[0082] remap network traffic to an intermediate IP address to the destination network location,
[0083] send network traffic to the intermediate IP address at the destination network location; and
[0084] remap network traffic and distribute network traffic to the target instance when it is received at the destination network location.
[0085] Clause 2. Method implemented by computer, as defined in Clause 1, which further comprises:
[0086] determine whether the sending of network traffic to the intermediate IP address at the destination network location will be carried out through a private network of a service provider that receives the network traffic or through the Internet.
[0087] Clause 3. Computer-deployed method as defined in claim 2, wherein the action of determining whether the sending of network traffic to the intermediate IP address will be performed over a private network or the Internet is based at least on part in a current load of the private network.
[0088] Clause 4. Computer-implemented method of directing network traffic, which comprises:
[0089] under the control of one or more computer systems configured with executable instructions,
[0090] receive network traffic for a service provider network, the network traffic being received at a remapable global address advertised from at least one point of the service provider network, each point capable of being at a location from different network and be mapped to a target destination in the service provider's network;
[0091] remapping the network traffic and distributing the network traffic to the target destination when a target network location of the target destination is the same as a receiving network location where the network traffic is received; and
[0092] when the destination network location is different from the receiving network location:
[0093] remap network traffic to an intermediate address from the service provider network to the destination network location,
[0094] send network traffic to the intermediate address at the destination network location; and
[0095] remap the network traffic and distribute the network traffic to the target destination when it is received at the destination network location.
[0096] Clause 5. A computer-deployed method, as defined in Clause 4, in which the remapable global address is advertised from at least two points in the service provider's network.
[0097] Clause 6. Computer-deployed method, as defined in Clause 4, wherein the remapable global address is a remapable global Internet Protocol (IP) address, and
[0098] in which the service provider allows global routing of network traffic using at least one of Domain Name System (DNS) or Border Passing Protocol (BGP) routing.
[0099] Clause 7. Method deployed per computer, as defined in Clause 4, in which the target destination corresponds to at least one virtual machine in a multi-user resource environment.
[00100] Clause 8. Method implemented by computer, as defined in Clause 4, in which a consumer corresponding to the target destination is entitled to present at least one policy useful in determining the target destination.
[00101] Clause 9. Computer-deployed method, as defined in Clause 7, wherein the consumer is able to present updated policies through at least one application programming interface (API).
[00102] Clause 10. Method deployed per computer, as defined in Clause 8, in which a consumer may present at least one policy per network location.
[00103] Clause 11. Method implemented by computer, as defined in Clause 4, in which the different network locations correspond to at least one of geographically dispersed regions or networks operated by different providers.
[00104] Clause 12. A computer-deployed method, as defined in Clause 4, wherein a policy for determining a target destination designates network locations to which network traffic will be directed at specific times of the day.
[00105] Clause 13. Computer deployed method, as defined in Clause 4, in which at least one policy is used to determine a target destination, the at least one policy determining the target destination based on at least one source location of the network traffic, a type of consumer corresponding to the network traffic, or a financial consideration amount associated with the network traffic.
[00106] Clause 14. Computer-deployed method as defined in Clause 4, wherein the target destination is determined using static configuration information that indicates a network location to which traffic will be routed based at least in part on a network location where network traffic is received.
[00107] Clause 15. Computer-deployed method, as defined in Clause 4, in which the target destination is dynamically determined based on factors including at least a current load of certain network locations and a network proximity to certain locations of network.
[00108] Clause 16. Computer-deployed method, as defined in Clause 4, in which the target destination is determined using a list that ranks multiple network locations and a list of network locations where the globally remapable address is active.
[00109] Clause 17. Computer-deployed method as defined in Clause 4, wherein the remapable global address may be advertised from network locations in at least one of different countries and different continents.
[00110] Clause 18. A computer-implemented method, as defined in Clause 4, in which network traffic may be sent to the intermediate address using a public or private network.
[00111] Clause 19. A computer-deployed method, as defined in Clause 4, wherein at least some of the mappings between the remapable global addresses, intermediate addresses, and destination addresses are unidirectional.
[00112] Clause 20. A computer-deployed method, as defined in Clause 4, wherein the remapable global address may be mapped to fewer network locations than a series of network locations from which the remapable global address is advertised.
[00113] Clause 21. Computer-deployed method, as defined in Clause 17, wherein at least one network location from which the remapable global address is advertised does not have local resources for which at least certain types of traffic can or are allowed to be transmitted for processing.
[00114] Clause 22. A computer-deployed method, as defined in Clause 4, wherein network traffic is directed using an anycast approach.
[00115] Clause 23. A computer-deployed method, as defined in Clause 4, in which a consumer may specify a weighted traffic balancing in which an approximate amount of incoming traffic is directed to at least one network location.
[00116] Clause 24. Computer-deployed method, as defined in Clause 4, where addresses are globally remapable to new virtual machines, and where existing transactions can be processed using a previous virtual machine, whereas new transactions are routed to a new virtual machine for processing.
[00117] Clause 25. System for managing network traffic, comprising:
[00118] a processor; and
[00119] a memory device that includes instructions that, when executed by the processor, cause the processor to:
[00120] receive network traffic for a service provider network, the network traffic being received at a remapable global address advertised from at least one point of the service provider network, each point capable of being at a location from different network and be mapped to a target destination in the service provider's network;
[00121] remap the network traffic and distribute the network traffic to the target destination when a target network location of the target destination is the same as a receiving network location where the network traffic is received; and
[00122] when the destination network location is different from the receiving network location:
[00123] remap network traffic to an intermediate address from the service provider network to the destination network location; and
[00124] send the network traffic to the intermediate address at the destination network location, so that it can be remapped and delivered to the target destination when it is received at the destination network location.
[00125] Clause 26. System, as defined in Clause 25, wherein the target destination is determined in accordance with at least one of a policy, rank list, network load, or static configuration.
[00126] Clause 27. System, as defined in Clause 25, in which network traffic may be sent to the intermediate address using a public or private network.
[00127] Clause 28. Non-transient computer-readable storage medium that stores instructions for managing network traffic, the instructions, when executed by a processor, cause the processor to:
[00128] receive network traffic for a service provider network, the network traffic being received at a remapable global address advertised from at least one point of the service provider network, and each point capable of being in a different network location and be mapped to a target destination in the service provider's network;
[00129] remap the network traffic and distribute the network traffic to the target destination when a target network location of the target destination is the same as a receiving network location where the network traffic is received; and
[00130] when the destination network location is different from the receiving network location:
[00131] remap network traffic to an intermediate address from the service provider network to the destination network location; and
[00132] send the network traffic to the intermediate address at the destination network location, so that it can be remapped and delivered to the target destination when it is received at the destination network location.
[00133] Clause 29. A non-transient computer-readable storage medium as defined in Clause 28, wherein at least some of the mappings between the remapable global addresses, intermediate addresses, and destination addresses are unidirectional.
[00134] As discussed above, the various modalities can be deployed in a wide variety of operating environments, which may in some cases include one or more user computers, computing devices, or processing devices that can be used to operate either among a number of applications. User or client devices can include any of a number of general purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless and handheld devices running mobile software and are compatible with a range of networking and messaging protocols. Such a system may also include a series of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as database development and management. These devices may also include other electronic devices such as dummy terminals, thin clients, computer gaming systems, and other devices capable of communicating over a network.
[00135] Various aspects can also be deployed as part of at least one service or web service, as can be part of a service-oriented architecture. Services such as web services can communicate using any type of appropriate messaging system, such as through the use of messages in Extensible Markup Language (XML) format and exchanged using an appropriate protocol such as SOAP (derived from “Simple Object Access Protocol”). The processes provided or executed by such services may be written in any appropriate language, such as the Web Services Description Language (WSDL). Using a language such as WSDL allows for functionality such as automated generation of client code in various SOAP frameworks.
[00136] Most modalities use at least one network that would be familiar to those skilled in the communications support technique with the use of any one of a variety of commercially available protocols, such as TCP/IP, OSI, FTP, UPnP, NFS, CIFS and AppleTalk. The network can be, for example, a local area network, a remote network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combinations thereof.
[00137] In embodiments that utilize a web server, the web server can run any of a variety of mid-level or server-side applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and servers of business applications. The server(s) may also run programs or scripts in response to requests from user devices, such as by running one or more web applications that can be deployed as one or more scripts or written programs in any programming language such as Java®, C, C# or C++, or any scripting language such as Perl, Python or TCL, as well as combinations thereof. The server(s) may also include database servers, including, without limitation, those commercially available from Oracle®, Microsoft®, Sybase® and IBM®.
[00138] The environment can include a variety of data stores and other storage and memory media, as discussed above. These can reside in a variety of locations, such as on a storage medium located (and/or resident) on one or more of the computers or remote from any or all of the computers on the entire network. In a particular set of modalities, information may reside on a storage area network (“SAN”) familiar to those skilled in the art. Similarly, any files needed to perform the functions assigned to computers, servers or other network devices can be stored locally and/or remotely, as appropriate. When a system includes computerized devices, each such device can include hardware elements that can be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one device. input devices (for example, a mouse, keyboard, controller, touch screen or numeric keypad) and at least one output device (for example, a display device, printer, or speaker). Such a system may further include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices, such as random access memory ("RAM") or read-only memory ("ROM") , as well as removable media devices, memory cards, flash memory cards, etc.
[00139] Such devices may also include a computer readable storage media reader, a communication device (e.g., a modem, a network interface card (wired or wireless), an infrared communication device, etc.). ) and working memory as described above. The computer-readable storage media reader may be connected to, or configured to receive, a computer-readable storage media, representing remote, local, fixed and/or removable storage devices, as well as storage media to contain, store, transmit and retrieve, temporarily and/or more permanently, computer-readable information. Typically, the system and various devices also include a series of software applications, modules, services or other elements located in at least one memory device including an operating system and application programs such as a client application or web browser. It should be appreciated that alternative modalities may have numerous variations from the one described above. For example, custom hardware can also be used and/or particular elements can be deployed in hardware, software (including portable software such as applets), or both. In addition, connection to other computing devices, such as network input/output devices, can be employed.
[00140] Storage media and computer readable media for containing code, or portions of code, may include any suitable media known or used in the art, including storage media and communication media, such as, without limitation, volatile and non-volatile media , removable and non-removable implanted in any method or technology for storing and/or transmitting information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, fast memory or other memory technology , CD-ROM, versatile digital disk (DVD) or other optical storage, magnetic cassette tapes, magnetic tapes, magnetic storage disk or other magnetic storage devices, or any other medium that can be used to store the desired information that can be accessed by a system device. Based on the disclosure and teachings provided herein, an element of common skill in the art will appreciate other modes and/or methods of implementing the various modalities.
[00141] The descriptive report and the drawings must therefore be considered in an illustrative rather than a restrictive sense. It is, therefore, evident that various modifications and changes can be made to this document without departing from the broader spirit and scope of the invention as defined in the claims.

权利要求:
Claims (25)
[0001]
1. Computer-deployed method of directing network traffic, characterized in that it comprises: under the control of one or more computer systems configured with executable instructions, receiving network traffic for a service provider network, the traffic of network being received to a remapable global address advertised from at least one point of the service provider network, each point capable of being in a different network location and being mapped to a target destination of the service provider network; network traffic and distribute the network traffic to the target destination when a destination network location of the target destination is the same as a receiving network location at which the network traffic is received; and when the destination network location is different from the receiving network location: remap the network traffic to an intermediate address of the service provider network to the destination network location, send the network traffic to the intermediate address; eremap network traffic and distribute network traffic to the target destination when network traffic is received at the intermediate address.
[0002]
2. Method according to claim 1, characterized in that the remapable global address is advertised from at least two points in the service provider network.
[0003]
3. Method according to claim 1, characterized in that the remapable global address is a remapable global Internet Protocol (IP) address, and in which the service provider allows the global routing of network traffic using at least one of Domain Name System (DNS) or boundary crossing protocol (BGP) routing.
[0004]
4. Method according to claim 1, characterized in that the target destination corresponds to at least one virtual machine in a multiuser resource environment.
[0005]
5. Method according to claim 1, characterized in that a consumer corresponding to the target destination is enabled to send at least one usable policy for determining the target destination.
[0006]
6. Method according to claim 5, characterized in that a consumer is able to send updated policies through at least one application programming interface (API).
[0007]
7. Method according to claim 5, characterized in that a consumer is able to send at least one policy per network location.
[0008]
8. Method according to claim 1, characterized in that the different network locations correspond to at least one among geographically dispersed regions or networks operated by different providers.
[0009]
9. Method according to claim 1, characterized in that a policy for determining a target destination designates network locations to which to direct network traffic at specific times of the day.
[0010]
10. Method according to claim 1, characterized in that at least one policy is used to determine a target destination, the at least one policy determining the target destination based on at least one of a traffic origin location network, a type of consumer corresponding to the network traffic, or an amount of the financial consideration associated with the network traffic.
[0011]
11. Method according to claim 1, characterized in that the target destination is determined using static configuration information that indicates a network location to which to route traffic based at least in part on a network location in the which network traffic is received.
[0012]
12. Method according to claim 1, characterized in that the target destination is dynamically determined based on factors that include at least one of the current load of certain network locations and a network proximity to certain network locations.
[0013]
13. Method according to claim 1, characterized in that the target destination is determined using a list that ranks various network locations and a list of network locations in which the globally remapable address is active.
[0014]
14. Method according to claim 1, characterized in that the global remapable address is capable of being advertised from network locations in at least one of the different countries and different continents.
[0015]
15. Method according to claim 14, characterized in that at least one network location of the global remapable address is advertised not having local resources for which at least certain types of traffic are able or authorized to be transmitted to process .
[0016]
16. Method according to claim 1, characterized in that the network traffic is able to be sent to the intermediary address using a public or private network.
[0017]
17. Method according to claim 1, characterized in that at least some of the mappings between remapable global addresses, intermediate addresses and destination addresses are unidirectional.
[0018]
18. Method according to claim 1, characterized in that the remapable global address is capable of being mapped to fewer network locations than to several network locations from which the global remapable address is advertised.
[0019]
19. Method according to claim 1, characterized in that the network traffic is directed using an anycast approach.
[0020]
20. Method according to claim 1, characterized in that a consumer is able to specify a weighted traffic balancing in which an approximate amount of the received traffic is directed to at least one network location.
[0021]
21. Method according to claim 1, characterized by the fact that addresses are globally remapable to new virtual machines, and in which existing transactions are able to be processed using a previous virtual machine, although new transactions are directed to a new virtual machine for processing.
[0022]
22. A computer-readable medium containing instructions, characterized in that the instructions, when executed by one or more computer systems, cause the method as defined in any one of claims 1 to 21 to be carried out.
[0023]
23. System for managing network traffic, characterized by the fact that it comprises: a processor; and a memory device that includes instructions that, when executed by the processor, cause the processor to: receive network traffic for a service provider network, the network traffic being received for a remapable global address advertised from at least one point of the service provider network, each point capable of being in a different network location and being mapped to a target destination of the service provider network; remap network traffic and distribute network traffic to the target destination when one target destination's destination network location is the same as a receiving network location at which network traffic is received; and when the destination network location is different from the receiving network location: remap the network traffic to an intermediate address from the service provider network to the destination network target location; esend network traffic to the intermediate address through which network traffic is able to be remapped and distributed to the target destination when network traffic is received at the intermediate address.
[0024]
24. System according to claim 23, characterized in that the target destination is determined according to at least one of a policy, classification list, network load or static configuration.
[0025]
25. System according to claim 23, characterized in that network traffic is able to be sent to the intermediate address using a public or private network.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112013021997B1|2021-09-08|COMPUTER DEPLOYED METHOD OF DIRECTING NETWORK TRAFFIC, COMPUTER-READABLE MEDIA AND SYSTEM FOR NETWORK TRAFFIC MANAGEMENT

---

US10997211B2|2021-05-04|Systems and methods for database zone sharding and API integration

---

US10977277B2|2021-04-13|Systems and methods for database zone sharding and API integration

---

US20210400112A1|2021-12-23|Redundant storage gateways

---

US9747179B2|2017-08-29|Data management agent for selective storage re-caching

---

CA2978183C|2021-01-26|Executing commands within virtual machine instances

---

JP5945031B2|2016-07-05|Provision and manage replicated data instances

---

US9426218B2|2016-08-23|Virtual storage appliance gateway

---

JP6177799B2|2017-08-09|Software deployment topology

---

ES2645414T3|2017-12-05|Failover and recovery for replicated data instances

---

Fifield et al.2014|OpenStack Operations Guide: Set up and manage your openstack cloud

---

US10657061B1|2020-05-19|Resource distribution using attributes of versioned hash rings

---

US20170013046A1|2017-01-12|Data-centric data storage

---

Aldwyan et al.2019|Latency-aware failover strategies for containerized web applications in distributed clouds

---

US9602341B1|2017-03-21|Secure multi-tenant virtual control server operation in a cloud environment using API provider

---

US10404613B1|2019-09-03|Placement of control and data plane resources

---

JP6823716B2|2021-02-03|Consistency hash configuration that supports multi-site replication

---

Salam et al.2015|Deploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification and Beyond: Exam CV0-001

---

US9817721B1|2017-11-14|High availability management techniques for cluster resources

---

Ward2013|NoSQL database in the cloud: MongoDB on AWS

---

US10922303B1|2021-02-16|Early detection of corrupt data partition exports

---

US10924452B1|2021-02-16|Auditing IP address assignments

---

US10929797B1|2021-02-23|Fault tolerance determinations for networked resources

---

Karthikeyan2018|Practical Microsoft Azure IaaS: Migrating and Building Scalable and Secure Cloud Solutions

---

US20210208971A1|2021-07-08|System and method for improved fault tolerance in a network cloud environment

同族专利:

---

公开号 | 公开日

---

AU2012225301B2|2015-03-12|

---

BR112013021997A2|2016-11-29|

---

EP2684065A4|2015-04-01|

---

JP5727053B2|2015-06-03|

---

US20120233329A1|2012-09-13|

---

CA2824598A1|2012-09-13|

---

CN103620597A|2014-03-05|

---

CN103620597B|2019-08-13|

---

WO2012122474A3|2013-11-28|

---

CA2824598C|2016-07-19|

---

SG191948A1|2013-08-30|

---

US10009315B2|2018-06-26|

---

EP2684065A2|2014-01-15|

---

JP2014512739A|2014-05-22|

---

WO2012122474A2|2012-09-13|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

JP3633321B2|1998-10-23|2005-03-30|富士通株式会社|Wide area load distribution apparatus and method|

---

US6415323B1|1999-09-03|2002-07-02|Fastforward Networks|Proximity-based redirection system for robust and scalable service-node location in an internetwork|

---

US20030046419A1|2001-08-31|2003-03-06|King Peter F.|Stateful load balancing|

---

KR100423500B1|2002-01-29|2004-03-18|삼성전자주식회사|Converting Apparatus for converting internet protocol address and Home network system using thereof|

---

EP1504370A4|2002-05-14|2008-05-21|Akamai Tech Inc|Enterprise content delivery network having a central controller for coordinating a set of content servers|

---

US7139840B1|2002-06-14|2006-11-21|Cisco Technology, Inc.|Methods and apparatus for providing multiple server address translation|

---

US20060112170A1|2004-05-03|2006-05-25|Craig Sirkin|Geo-locating load balancing|

---

US8250175B2|2006-08-02|2012-08-21|Cisco Technology, Inc.|Techniques for remapping content requests|

---

US8195736B2|2006-08-08|2012-06-05|Opnet Technologies, Inc.|Mapping virtual internet protocol addresses|

---

CN1988492A|2006-11-28|2007-06-27|华为技术有限公司|Method for intercommunication between network nodes, for access service network and WiMAX network frame|

---

US9143558B2|2007-05-09|2015-09-22|Radware, Ltd.|Geographic resiliency and load balancing for SIP application services|

---

US8825816B2|2007-10-24|2014-09-02|Lantronix, Inc.|Various methods and apparatuses for a central management station for automatic distribution of configuration information to remote devices|

---

US8190158B2|2008-09-22|2012-05-29|Cellco Partnership|Robust and fast inter-EBS handoff mechanism|

---

US20100223364A1|2009-02-27|2010-09-02|Yottaa Inc|System and method for network traffic management and load balancing|

---

US8429647B2|2009-05-06|2013-04-23|Vmware, Inc.|Virtual machine migration across network by publishing routes to the associated virtual networks via virtual router after the start of migration of the virtual machine|

---

US8345692B2|2010-04-27|2013-01-01|Cisco Technology, Inc.|Virtual switching overlay for cloud computing|US7970820B1|2008-03-31|2011-06-28|Amazon Technologies, Inc.|Locality based content distribution|

---

US8447831B1|2008-03-31|2013-05-21|Amazon Technologies, Inc.|Incentive driven content delivery|

---

US8321568B2|2008-03-31|2012-11-27|Amazon Technologies, Inc.|Content management|

---

US8601090B1|2008-03-31|2013-12-03|Amazon Technologies, Inc.|Network resource identification|

---

US7962597B2|2008-03-31|2011-06-14|Amazon Technologies, Inc.|Request routing based on class|

---

US8606996B2|2008-03-31|2013-12-10|Amazon Technologies, Inc.|Cache optimization|

---

US8073940B1|2008-11-17|2011-12-06|Amazon Technologies, Inc.|Managing content delivery network service providers|

---

US7991910B2|2008-11-17|2011-08-02|Amazon Technologies, Inc.|Updating routing information based on client location|

---

US8122098B1|2008-11-17|2012-02-21|Amazon Technologies, Inc.|Managing content delivery network service providers by a content broker|

---

US8028090B2|2008-11-17|2011-09-27|Amazon Technologies, Inc.|Request routing utilizing client location information|

---

US8688837B1|2009-03-27|2014-04-01|Amazon Technologies, Inc.|Dynamically translating resource identifiers for request routing using popularity information|

---

US8756341B1|2009-03-27|2014-06-17|Amazon Technologies, Inc.|Request routing utilizing popularity information|

---

US8412823B1|2009-03-27|2013-04-02|Amazon Technologies, Inc.|Managing tracking information entries in resource cache components|

---

US8782236B1|2009-06-16|2014-07-15|Amazon Technologies, Inc.|Managing resources using resource expiration data|

---

US8397073B1|2009-09-04|2013-03-12|Amazon Technologies, Inc.|Managing secure content in a content delivery network|

---

US8433771B1|2009-10-02|2013-04-30|Amazon Technologies, Inc.|Distribution network with forward resource propagation|

---

US9495338B1|2010-01-28|2016-11-15|Amazon Technologies, Inc.|Content distribution network|

---

US8468247B1|2010-09-28|2013-06-18|Amazon Technologies, Inc.|Point of presence management in request routing|

---

US10958501B1|2010-09-28|2021-03-23|Amazon Technologies, Inc.|Request routing information based on client IP groupings|

---

US9407681B1|2010-09-28|2016-08-02|Amazon Technologies, Inc.|Latency measurement in resource requests|

---

US10097398B1|2010-09-28|2018-10-09|Amazon Technologies, Inc.|Point of presence management in request routing|

---

US9712484B1|2010-09-28|2017-07-18|Amazon Technologies, Inc.|Managing request routing information utilizing client identifiers|

---

US9003035B1|2010-09-28|2015-04-07|Amazon Technologies, Inc.|Point of presence management in request routing|

---

US8452874B2|2010-11-22|2013-05-28|Amazon Technologies, Inc.|Request routing processing|

---

US8954978B1|2010-12-29|2015-02-10|Amazon Technologies, Inc.|Reputation-based mediation of virtual control planes|

---

US8667399B1|2010-12-29|2014-03-04|Amazon Technologies, Inc.|Cost tracking for virtual control planes|

---

US8667495B1|2010-12-29|2014-03-04|Amazon Technologies, Inc.|Virtual resource provider with virtual control planes|

---

US10623408B1|2012-04-02|2020-04-14|Amazon Technologies, Inc.|Context sensitive object management|

---

US9154551B1|2012-06-11|2015-10-06|Amazon Technologies, Inc.|Processing DNS queries to identify pre-processing information|

---

US9323577B2|2012-09-20|2016-04-26|Amazon Technologies, Inc.|Automated profiling of resource usage|

---

US9537973B2|2012-11-01|2017-01-03|Microsoft Technology Licensing, Llc|CDN load balancing in the cloud|

---

US9374276B2|2012-11-01|2016-06-21|Microsoft Technology Licensing, Llc|CDN traffic management in the cloud|

---

US10205698B1|2012-12-19|2019-02-12|Amazon Technologies, Inc.|Source-dependent address resolution|

---

US9294391B1|2013-06-04|2016-03-22|Amazon Technologies, Inc.|Managing network computing components utilizing request routing|

---

US20150066560A1|2013-08-27|2015-03-05|Connectloud, Inc.|Method and apparatus for managing multi-vendor infrastructure for software defined clouds through abstracted control planes|

---

US9628436B1|2014-04-04|2017-04-18|8X8, Inc.|User-configurable dynamic DNS mapping for virtual services|

---

US10033627B1|2014-12-18|2018-07-24|Amazon Technologies, Inc.|Routing mode and point-of-presence selection service|

---

US10091096B1|2014-12-18|2018-10-02|Amazon Technologies, Inc.|Routing mode and point-of-presence selection service|

---

US10097448B1|2014-12-18|2018-10-09|Amazon Technologies, Inc.|Routing mode and point-of-presence selection service|

---

US10225326B1|2015-03-23|2019-03-05|Amazon Technologies, Inc.|Point of presence based data uploading|

---

US9887932B1|2015-03-30|2018-02-06|Amazon Technologies, Inc.|Traffic surge management for points of presence|

---

US9887931B1|2015-03-30|2018-02-06|Amazon Technologies, Inc.|Traffic surge management for points of presence|

---

US9819567B1|2015-03-30|2017-11-14|Amazon Technologies, Inc.|Traffic surge management for points of presence|

---

US10678762B2|2015-05-01|2020-06-09|Microsoft Technology Licensing, Llc|Isolating data to be moved across boundaries|

---

US10261943B2|2015-05-01|2019-04-16|Microsoft Technology Licensing, Llc|Securely moving data across boundaries|

---

US10229124B2|2015-05-01|2019-03-12|Microsoft Technology Licensing, Llc|Re-directing tenants during a data move|

---

US9832141B1|2015-05-13|2017-11-28|Amazon Technologies, Inc.|Routing based request correlation|

---

US10097566B1|2015-07-31|2018-10-09|Amazon Technologies, Inc.|Identifying targets of network attacks|

---

US9774619B1|2015-09-24|2017-09-26|Amazon Technologies, Inc.|Mitigating network attacks|

---

US10270878B1|2015-11-10|2019-04-23|Amazon Technologies, Inc.|Routing for origin-facing points of presence|

---

US10049051B1|2015-12-11|2018-08-14|Amazon Technologies, Inc.|Reserved cache space in content delivery networks|

---

US10257307B1|2015-12-11|2019-04-09|Amazon Technologies, Inc.|Reserved cache space in content delivery networks|

---

US10348639B2|2015-12-18|2019-07-09|Amazon Technologies, Inc.|Use of virtual endpoints to improve data transmission rates|

---

US10075551B1|2016-06-06|2018-09-11|Amazon Technologies, Inc.|Request management for hierarchical cache|

---

US10110694B1|2016-06-29|2018-10-23|Amazon Technologies, Inc.|Adaptive transfer rate for retrieving content from a server|

---

US9992086B1|2016-08-23|2018-06-05|Amazon Technologies, Inc.|External health checking of virtual private cloud network environments|

---

US10033691B1|2016-08-24|2018-07-24|Amazon Technologies, Inc.|Adaptive resolution of domain name requests in virtual private cloud network environments|

---

US10469513B2|2016-10-05|2019-11-05|Amazon Technologies, Inc.|Encrypted network addresses|

---

US10216379B2|2016-10-25|2019-02-26|Microsoft Technology Licensing, Llc|User interaction processing in an electronic mail system|

---

US10372499B1|2016-12-27|2019-08-06|Amazon Technologies, Inc.|Efficient region selection system for executing request-driven code|

---

US10831549B1|2016-12-27|2020-11-10|Amazon Technologies, Inc.|Multi-region request-driven code execution system|

---

US10938884B1|2017-01-30|2021-03-02|Amazon Technologies, Inc.|Origin server cloaking using virtual private cloud network environments|

---

US10601768B2|2017-04-10|2020-03-24|Verizon Digital Media Services Inc.|Automated steady state traffic management|

---

US10503613B1|2017-04-21|2019-12-10|Amazon Technologies, Inc.|Efficient serving of resources during server unavailability|

---

US11075987B1|2017-06-12|2021-07-27|Amazon Technologies, Inc.|Load estimating content delivery network|

---

US10447648B2|2017-06-19|2019-10-15|Amazon Technologies, Inc.|Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP|

---

CN107301084B|2017-07-05|2020-04-21|深圳先进技术研究院|Virtual machine migration method and device of cluster server, server and storage medium|

---

US10592578B1|2018-03-07|2020-03-17|Amazon Technologies, Inc.|Predictive content push-enabled content delivery network|

---

US10819677B2|2018-07-16|2020-10-27|Amazon Technologies, Inc.|Address migration service|

---

US10862852B1|2018-11-16|2020-12-08|Amazon Technologies, Inc.|Resolution of domain name requests in heterogeneous network environments|

---

US11025747B1|2018-12-12|2021-06-01|Amazon Technologies, Inc.|Content request pattern-based routing system|

法律状态:
2018-12-18| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-10-22| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2021-03-16| B06A| Patent application procedure suspended [chapter 6.1 patent gazette]|

---

2021-07-13| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-09-08| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 09/03/2012, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US13/044,494|US10009315B2|2011-03-09|2011-03-09|Outside live migration|

---

US13/044,494|2011-03-09|

---

PCT/US2012/028480|WO2012122474A2|2011-03-09|2012-03-09|Outside live migration|

---